デザインと開発プロセス

小峰健範

2023.05.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、CX事業本部デザインチームの小峰です。

デザイン領域の作業が開発プロセスと分断されてしまっている、という話をよく聞きます。例えばスプリントゼロと呼ばれるフェーズを組み、事前にデザインを作成しその後のエンジニア作業に備える、というプロセスをよく目にします。Googleで「スクラムデザイン」というキーワードで検索してみても、多くの人たちが悩んでいたり工夫していたりするのを多く目にします。

最良の方法はあるのでしょうか？　少なくともスプリントゼロという取り組みは有用だったとしても、アジャイルやスクラムの理念からはちょっと外れているように見受けられます。

今回は、オライリーのLean UX 第3版を参考に引用を交えつつ、これについて考えてみます。

その前に1つ注意を。

UXデザインやアジャイル、スクラムについては膨大な情報があり、その捉え方、解釈の仕方、活用の仕方は千差万別です。これを読んでくださっている皆さんを取り巻く環境、状況、チームメンバーの価値観、対象となるプロダクトなど、様々な要素が複雑に絡み合う中での最適解は当然ながらひとつではありません。

ここに書いていることもあくまでのひとつの解釈として捉えていただき、何らかの参考になれば幸いです。

そもそもLean（リーン）とは？

リーンの考え方を含むものは意外とあります。

例えばLean Startup（リーンスタートアップ）という言葉もあります。エリック・リース氏によって考案された新しいビジネスの創出のために考案された新規事業開発および起業プロセスです。かなり大雑把に言えばMVP（Minimum Viable Product）と呼ばれるほぼプロトタイプのようなプロダクトを高速でつくり、早期に市場の反応を見て、そこから学習しブラッシュアップしていくようなプロセスです。

Lean UXとLean Startup、どちらにもLean（リーン）という言葉が含まれています。リーンとは何でしょうか？　言葉としては「引き締まった」「贅肉がない」といった意味合いを持ちます。

リーンの源流はトヨタ生産方式と呼ばれています。それまでは大勢だったアメリカ式の大量生産方式へのアンチテーゼのような考え方です。

フォード・モーター社などは大量生産方式を生み出しました。これは対象となるプロダクトの標準化、パーツの規格化、製造工程の細分化といったことにより生産をベルトコンベアによる流れ作業として、作業がシンプル化し熟練工を不要とするものでした。また、これによって大量生産によるコストダウン、製品の低価格化を実現しています（根底にはFordism（フォード主義）という思想があるようです）。ただしこれによって作業員のモチベーションは著しく低下し、在庫の維持費に悩まされるという弊害も生んでしまったようです。フォード・モーター社の創設者ヘンリー・フォード氏は「雇いたいのは壊れずに丈夫で正確な手と足なのだが、人間を雇うと面倒な頭と心が付いてくる」ということを言っていた、ということをどこかで目にした覚えがあります（うろ覚えです）。人の扱いに困っていたように見受けられますね。ダグラス・マクレガー氏によるXY理論やアブラハム・マズロー氏による欲求5段階説といった話にも繋がりますが……一旦ここまでにしておきましょう（参考：XY理論 - Wikipedia）

さて、トヨタは今でこそ世界的な企業ですが、第二次世界大戦直後は倒産寸前の危機にまで陥っていたようです。自動車は多くの資本がなければ活動できない事業です。そこでトヨタは在庫の維持費という「金額的コスト」から「時間的コスト」に着目しました。つまり在庫を大量に抱えることなく受注があったらすぐ製品を作ればいい、という考え方に切り替えたのです。この成功によって日本のモータリゼーションを先導し、高度経済成長期のマイカーブームを牽引したと言われています。

すぐ製品をつくるためにどうすればいいのか？　それを突き詰めていった結果がリーンと言ってもいいでしょう。「ダ・ラ・リ」と略されることもある「ムダ・ムラ・ムリ」を徹底的に排除し、良いものだけを効率よく作るという考え方が根底にあります。

「ダ・ラ・リ」が減っていった結果、「必要なものを、必要なときに、必要な量だけ」つくることができるようになりました。トヨタ生産方式が「JIT（ジャスト・イン・タイム）方式」とも呼ばれる所以です。

このトヨタ生産方式、元を辿るとアメリカのロッキード社が航空機工場でスーパーマーケット方式を利用していたことから着想を得たようです。アメリカのスーパーマーケットを参考した結果、アメリカの自動車生産方式の対極になるようなものを生み出すことになるとはなんとも皮肉めいた話ですが……まぁその話はメインではないので、これもこのあたりで（参考：トヨタ企業サイト｜トヨタ自動車75年史｜第1部第2章第7節｜第4項スーパーマーケット方式）

リーンには様々な考え方や捉え方があって一言で表すことは難しいですが、現在の私の考えとしてはトヨタ生産方式にならって、

「ムダ・ムラ・ムリ」を徹底的に排除すること
「必要なものを、必要なときに、必要なだけ」つくること

という理解をしており、そしてこれは近年のビジネスにおいて、極めて重要な考え方のひとつではないかと思っています。

Lean UXの基盤

Lean UXはいくつかの異なる考え方が組み合わされています。これらの基盤となる考え方を理解しておく必要があります。

基盤1:ユーザーエクスペリエンス・デザイン

人間工学や認知心理学といった人の活動や考え方といった分野に根差しており、工業デザイナーの仕事を通じて生まれた「人間中心デザイン」というアイデアに基づく多様な考え方や手法があります。そういったものを包括して、近年ではユーザーエクスペリエンス・デザイン（また単にUX）という用語で呼ばれています。

UXはインタラクションデザイン、情報アーキテクチャ、グラフィックデザインなど多くのデザイン分野を包含しています。

またデザイン思考という言葉もあります。IDEOのティム・ブラウン氏は

人間を直接的に観察することを原動力とするイノベーション手法。人々が暮らしのなかで何を望み、必要としているか、特定のプロダクトの製造やパッケージング、マーケティング、販売、サポートの方法で何を好み、好んでいないかを直接的に観察することを原動力とするイノベーション手法である

人々のニーズを技術的に実現可能なことと、事業戦略によってユーザー価値と市場価値に転換できるものに適合させるために、デザイナー的な感性や手法を用いる方法である

と定義しています。

Lean UXは「ビジネスのあらゆる側面は、デザイン手法でアプローチできる」という明確な立場を取っています。デザイナーは従来の役割に制限されることなく、あらゆる境界線を超えて仕事をする必要があります。

UXとデザイン思考はチーム全体にヒューマンニーズの考慮と、様々な役割のコラボレーション、全体的な視点でのプロダクトデザインを促す重要な基盤のひとつです。

基盤2:アジャイルソフトウェア開発

もうこれはアジャイルソフトウェア開発宣言とアジャイル宣言の背後にある原則を読んでいただくことが最も良いでしょう。

手前味噌ですが、私が以前書いた、

も参考にしていただけると嬉しいです。

基盤3:リーン・スタートアップ

冒頭にも紹介したリーン・スタートアップもLean UXの基盤のひとつとされています。これは「構築（Build）、計測（Measure）、学習（Learn）」のフィードバックループを用いてプロジェクトのリスクを最小化し、開発と学習を迅速化するサイクルのことを指します。

提唱者のエリック・リース氏は、

リーン・スタートアップはプロトタイプの迅速な開発を提唱している。狙いは、市場における仮説の評価とユーザーからのフィードバックの活用により、従来のソフトウェア・エンジニアリング手法よりも短期間でプロダクトやサービスを進化させることだ

リーン・スタートアップのプロセスは、ユーザーとの接触頻度を増やすことで無駄を削減する。これにより、マーケットにおいて速やかに仮説を検証し、間違っていた場合はそれをすぐに回避できるようになる

と述べています。

Lean UXではこの思想をプロダクトデザインに適用しています。

Lean UXの定義

これら基盤により、Lean UXは下記のように定義されます。

Lean UXとは、コラボレーティブ、部門横断的、ユーザー中心の方法によって、プロダクトの本質を素早く明らかにするためのデザインアプローチである
Lean UXの手法は、ユーザー、ユーザーのニーズ、ソリューション案、成功の定義についてのチームの共通理解を構築する
Lean UXは、チームの意思決定に求められる根拠を築き、プロダクトやサービス、価値の提供を絶えず向上させるために、継続的な学習を優先させる

Lean UXの原則

多くの原則が存在しますがそれらを詳しく解説することは難しいため、書籍を参考にしていただくのが良いでしょう。ここではどんなものがあるかの紹介に留めます。

原則1:チームビルディング

部門横断的
小規模、専念、同一環境で作業する
自己充足的で、権限を持つ
課題焦点型

原則2:チームや組織文化の指針

疑問から確信へ
結果（アウトプット）ではなく、成果（アウトカム）を重視する
無駄を省く
共通理解を生み出す
ユニコーン、エバンジェリストやヒーローは不要
失敗を許容する

原則3:プロセスの指針

「これまでと同じことを速くやる」のではなく、仕事の進め方を見直す
プロダクト開発のフェーズに注意する
アジリティの鍵はイテレーション（反復）
バッチサイズを小さくしてリスクを減らす
継続的な発見を活用する
建物から出る
仕事を外面化する
分析よりも形にすることを優先させる
中間生成物中心の仕事の進め方から脱却する

デザインとアジャイル開発プロセスは融合できるのか？

さてようやく本題です。ここからはデザインとアジャイル開発に焦点を当てていきます。最近では多くの企業がアジャイル開発を採用していることでしょう。しかし、その中にデザインはどの程度組み込まれているでしょうか？　「すべてうまくいっている」と答えられる組織やチームは少ないと思います。デザインとエンジニアリングに関連する課題を抱えている企業も多いのではないでしょうか？

ここではLean UX 第3版の「第16章 Lean UXとアジャイル開発の融合」を参考にこれを紐解いていきます。

スプリントゼロ

当然ながらLean UXでは「デザインとアジャイル開発プロセスは融合できるもの」としています。しかしながら、現実ではプログラムを書くというプロセスとデザインをつくるというプロセスが著しく分断されていることが多いのではないでしょうか？

アジャイル開発とUXデザインを組み合わせることの先駆けとなった論文があります。デザレイ・サイ氏による「Adapting Usability Investigations for Agile User-centerd Design」というものです。この中ではアジャイル開発とユーザー中心デザインの共存方法についての詳細なアイデアが述べられています。これらの技法は「サイクルゼロ」と呼ばれていました。後に「スプリントゼロ」「スタッカードスプリント」と呼ばれるようになったとのことです。私としては「スプリントゼロ」という呼び名に馴染んでいるため、以降「スプリントゼロ」と呼ぶことにします。

これは端的に言えば「開発の1スプリント前に先行してデザイン活動を行う」というものです。こういう考え方で取り組んでいる方々もいらっしゃるかと思います。事実、私自身も以前はこういった取り組みをしているチームにいたこともありますし、現在のクラスメソッド内の開発プロセスにおいてもこういった流れがあるように見受けられます。

多くの人たちはこのモデルを誤解しているようです。

デザレイ・サイ氏は常に、

デザインのスプリントと開発のスプリントの両方でデザイナーとエンジニアが密接にコラボレーションすべき

と主張していました。にも関わらず、多くのチームはこの重要なポイントを見逃し、デザイナーとエンジニアが成果物を「手渡し」するコミュニケーションするワークフローをつくりました。一種の「ミニ・ウォーターフォール」と呼ぶべきプロセスです。この記事の冒頭に例で挙げた「スプリントゼロ」がまさにこれです。

とはいえこのワークフローによるメリットはゼロではありません。ウォーターフォールからアジャイルへ移行に取り組んでいるようなチームなら、過渡期の施策としては有効でしょう。短期間のサイクルで作業する方法、仕事を適切なバッチサイズに分割するといった方法を学びやすいからです。しかし、有効なのはあくまでも移行期だからであり、チームが最終的に目指す到達点ではありません。

この「ミニ・ウォーターフォール」状態における課題としては、

チーム全体が同じことに取り組んでいない状況が生じやすくなる
デザイナーからエンジニアへのドキュメント作成といった無駄が生じやすい
デザインのスプリント期間中、エンジニアからのフィードバックが得にくい
エンジニアがデザインに対する実現可能性やスコープを評価するチャンスがない

といったものがあります。他にもあるかもしれません。

アジャイル開発といいつつも、デザインがそのプロセスに統合されていないことは多くあると思います。デザインを社内エージェントして運営されている共有のサービスとして見なされています。そのために、デザイナーはアジャイル開発チームへの本質的なアサインがされません。デザイナーは開発を開始するための依存関係の1つに留まっています。

組織がスプリントゼロを手放せないのはアジャイル開発を完全に受け入れることができていないからです。スプリントゼロは正しい方向への足がかりにはなりますが、それを利用していることはチームがまだ目的地に到達していないことの証拠でもあります。

目標とすべきは、デザイナーとエンジニア間のコラボレーションと透明性を高め、ドキュメントの手渡し、長時間のデザインレビュー、機能交渉などの無駄を減らすことです。

「デュアルトラックアジャイル」モデル

デュアルトラックアジャイルとは、プロダクト開発における

ディスカバリー（顧客のためのソリューションを考え抜く）
デリバリー（安心・満足できる価値を安定して顧客に提供する）

この2つを1つのプロセスに統合したモデルです。

それぞれを個々のチームが受け持つのではなく、1つのチームで機能させることが重要です。

画像引用元： Level Up with Dual Track Agile — Hard Yards

ディスカバリ作業は大きく2つの要素に分けることができます。

デザインやリサーチ活動を通じた能動的な学習
すでに市場にある機能やプロダクトの分析を通じた受動的な学習

ディスカバリとデリバリーの作業量はスプリント毎に変動するでしょう。一定のバランスではないということを考慮しスプリント計画を練る必要があります。

ディスカバリ作業には共通理解を深めるためにできるだけ多くのチームメンバーが参加することが望ましいでしょう。ディスカバリ作業が正しく行われれば、多くのアイデアが変更され、破棄されることになります。機能をテストし、学習し、時にはリリース直前で機能そのものを破棄することも起こりえます。これはまさに、アジャイルソフトウェア開発宣言における「計画に従うことよりも変化への対応」に該当します。

デュアルトラックアジャイルを成功させ、デザインをチームの日常的なワークフローに組み込むために必要な構造的要素がいくつかあります。

要素1:チームに専任のデザイナーを配置する

プロダクト開発においてプログラムのコーディングは目的ではありません。プロダクトを通して顧客に価値を届けることが目的です。デザイナーがいないチームは単なるソフトウェアエンジニアリングチームです。チームはUXを提供するでしょうが、デザイナーがいる場合と同じレベルの品質に到達することは難しいでしょう。デザイナーがいない場合、ディスカバリ作業をするためのスキルが不足してしまい、結果コーディングに集中することになります。繰り返しになりますが、コーディングは手段であり目的ではありません。顧客と顧客のニーズに応える最善策に対する深い理解が必要であり、それをチームにもたらすのがデザイナーの役割です。

要素2:ディスカバリを、バックログで同じように扱う

コーディング作業、QA作業、デザイン作業、リサーチ作業など、すべての作業は1つのバックログに収めるべきです。そのすべての作業を行うチームメンバーが協力して優先順位を決めます。もし複数のバックログに分割した場合、チームはそのうちの1つを「主要な」バックログとみなし、他を軽視することに繋がります。

デザイン関連の作業がソフトウェア開発の作業と同じレベルにあることをチームにはっきりと示せます。ディスカバリ作業を行うために必要なトレードオフも検討しやすくなるでしょう。

このような場合によく問題として浮上するのが、「ベロシティの低下」です。ディスカバリ作業を行うことでチームのベロシティが下がってしまう、という意見です。もし、デリバリー作業のみでベロシティを測定しているのであれば答えはイエスです。しかし、デュアルトラックアジャイルにおいてはディスカバリ作業もベロシティ計測の対象です。そして、ディスカバリ作業が増えれば、必然的にデリバリー作業が減ります。チームメンバーが協力して両方に取り組むためです。

結局、大切なことはチームのアウトカムの最大化です。そのためにはどれだけデリバリーできたか、ソフトウェアをどれだけ構築したか、コードを書いたか、ではなく、成果を追跡しなければなりません。そのためにもディスカバリ作業は必要になります。

要素3:部門を超えた学習活動への参加

誰が主導するかにかかわらず、学習活動はチーム全体が実践・参加すべきですチーム全体での学びが増えるほど、学びの内容を共有・議論するための時間が減り、学んだことに基づいて何をすべきかを決定するために多くの時間を費やせるようになります。

チームメンバー全員がすべての活動に必ず参加せよ、と言っているわけではありません。誰もがある程度は参加すべきであり、参加することを特別なイベントとみなさず、日常的な活動の一部にすべきです。

アジャイル開発におけるデザイナーへの時間的プレッシャー

アジャイル開発手法は、デザイナーに時間的なプレッシャーを与えることがあります。2週間のイテレーティブプロセスで開発とデザインを並行して行うとき、デザイナーには目の前の大きな問題について熟考できる時間はほとんどありません。なぜなら作業を2週間のうちに終わらせるという「コミットメント」を求められるからです。スクラムで言うところの5つの価値基準のうちのひとつ「確約」です。

ただ、こういう状況になってしまう要因、デザイナーがアジャイル開発において大きなプレッシャーを感じる大きな理由は、何らかの理由によって開発プロセスに完全な形で参加できないことです。これはデザイナーのミスではありませんが、デザイナーも含む多くのメンバーが「アジャイルはソフトウェア開発手法なのだから、エンジニア以外の人間を関わらせる必要はない」と思っているからです。

すべてのアジャイル活動にチームで参加しよう

Lean UXを機能させ、アジャイル開発プロセスにデザイナーが滑らかに参加するためには、チーム全体がすべてのアジャイル活動に参加すべきです。チームには部門や職能横断的なメンバーが含まれます。何をどうやって開発すべきかをチーム内で交渉しやすくし、バックログの優先順位付けを連携して行うことができます。

例えばプランニング時にデザイナーが不在だったとしましょう。機能開発のために何らかのデザイン作業が必要です。しかし対象となるユーザーストーリーの開発について必要なデザイン作業は、エンジニアが考える以上に必要なものですが、プランニングにデザイナーが不在であったがためにその懸念を伝えることができませんでした。翌日のデイリースタンドアップミーティングにおいてそれが明るみに出ますが、プロダクトオーナーも含め、プランニング計画の合意が取られてしまっており、プロジェクトマネージャーやその他のチームメンバーが調整のために奔走することになります。顧客企業の責任者や事業の責任者に対しての情報共有、説明、合意形成や軌道修正に対する意思決定を得る必要があるでしょう。

もし、デザイナーがプランニングに参加して懸念を表明することができていたら、チームは別のユーザーストーリーを選択することができたかもしれませんし、懸念に対する対策を相談できたかもしれません。

全員が参加すると共通理解を得ることができます。チームの意思決定の多くはミーティングで行われます。たとえその内容の9割が自分自身にあまり関係がないものだっとしても、残りの1割は関係するものです。その情報が得られるだけでも、その後の作業効率の向上に繋がります。さらにミーティングに参加することで自身の作業についてチームと交渉することもできます。チームにはこのようなコラボレーションが必要で、チームのアウトカム最大化を目指ことが重要です。

スクラムで言うところの三本柱、「透明性」「検査」「適応」が該当するでしょう。

真にアジャイルでリーンな組織となるために

1つのチームに部門や職能の壁を超えてエンジニアもデザイナーも参加しよう、ということは1つのチームでの実践になります。しかし当然ながら企業は複数の部門、プロダクト、チーム、職能が入り乱れた構造です。チームの数が増え、プロダクト開発のストリームが膨大になった場合、どのような実践をすべきでしょうか？

プロダクトが上手くいくと組織が拡大していくのはある種の必然です。このスケーリングの問題についての一般的な答えはないように見受けられます。Scrum@ScaleやLeSS、SAFe、DADなど様々な複数チームによるアジャイル、エンタープライズアジャイルを調べたことがありますが、それぞれの主義思想、手法があり何がうまくいくかは誰にもわかりません。

デザイナーの活動、エンジニアの活動、それを滑らかにするためにLean UXを参考にして動こう、というのがこの記事のアプローチのひとつですが、他にも有用なものはあるでしょう。しかし、どういった考え方ややり方を実行し上手くいったとして、おそらくどんな状況においても何らかのタイミングにおいて「組織の課題」に当たるはずです。

複雑さが増し、規模が拡大していく状況下において、迷ったときや困ったときには根底を改めて見つめ直してみると良いかと思います。

この記事の文脈における根っこはなんでしょうか？

はい、最初に書いたLean（リーン）です。